1. Field of the Invention
The invention is related to packet-switched mobile communications systems. More specifically it relates to determining a Home Agent with Specific Binding in mobile communication based on the Mobile Internet Protocol (Mobile IP) or similar protocols.
2. Prior Art
The invention is described for the example of the Mobile Internet Protocol version 6 (Mobile IPv6). It is, however, also applicable to other protocols defining equivalent entities corresponding to the described entities of the Mobile IP.
To implement Mobile IPv6, you need a Home Agent on the home subnet on which the Mobile Node's home address resides. The IPv6 home address (HoA) is assigned to the Mobile Node. The Mobile Node obtains a new IPv6 address (the CoA) on networks to which it connects. The Home Agent accepts binding updates from the Mobile Node informing the Home Agent of the Mobile Node's location. The Home Agent then acts as proxy for the Mobile Node, intercepting traffic to the Mobile Node's home address and tunneling it to the Mobile Node.
The Home Agent is one of three key components in Mobile IPv6. The Home Agent works with the Correspondent Node and Mobile Node to enable Mobile IPv6 functionality. The Home Agent maintains an association between the Mobile Node's home IP or IPv6 address and its CoA (loaned address) on the foreign network. The Correspondent Node is the destination IP or IPv6 host in session with a Mobile Node. The Mobile Node is an IP or IPv6 host that maintains network connectivity using its home IP or IPv6 address, regardless of the link (or network) to which it is connected.
A separate binding cache is maintained by each Home Agent and optionally by a Correspondent Node for each of its IPv6 addresses. When the router sends a packet, it searches the binding cache for an IPv6 address before it searches the neighbor discovery conceptual destination cache. The binding cache for any one of a node's IPv6 addresses may contain one entry for each Mobile Node home address. The contents of all of a node's binding cache entries are cleared when it reboots. Binding cache entries are marked either as home registration or correspondent registration entries, depending on whether it is stored in a Home Agent or a Correspondent Node. A home registration entry is deleted when its binding lifetime expires; other entries may be replaced at any time through a local cache replacement policy.
If a Mobile Node (MN) moves between subnets, it must change its IP address to a topologically correct one. The reason is the hierarchical routing structure of the Internet, i.e., the IP addresses do not only serve identification purposes, but also contain location information. However, since connections on higher layers such as TCP (Transport Layer Protocol) connections are defined with the IP addresses (and ports) of the communicating nodes, the connection breaks if one of the nodes changes its IP address due to movement.
Mobile IPv6 [D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, IETF RFC 3775, June 2004] is a layer 3 mobility protocol that enables MNs to move between subnets in a transparent manner for higher layers, i.e. without breaking higher-layer connections. Therefore, an MN uses two IP addresses: a Care-of-Address (CoA) and a Home Address (HoA). The MN's higher layers use the HoA for communication with the Corresponding Node (CN). This address does not change and serves the purpose of identification of the MN. Topologically, it belongs to the home network of the MN. In contrast, the CoA changes on every movement resulting in a subnet change and is used as the locator for the routing infrastructure. Topologically, it belongs to the network the MN is currently visiting. One out of multiple Home Agents (HA) located on the home link maintains a mapping of the MN's CoA to the MN's HoA and redirects incoming traffic for the MN to its current location.
Reasons for having multiple HAs on the home link instead of a single HA are redundancy and load balancing. When bootstrapping in a foreign network, a mobile node needs to know the IP address of one of the HAs in order to be able to register with this HA. Since an HA might not always be reachable, e.g., because it has crashed or because the administrator updates hardware or software, an MN shall be able to dynamically discover an HA address. Multiple methods exist to solve this problem.
Included in IPv6 is a new addressing method called “anycasting” in addition to unicasting and multicasting known from IPv4. Unicast is a communication between a single host and a single receiver. Packets sent to a unicast address are delivered to the interface identified by that address, multicast is communication between a single host and multiple receivers. Packets are sent to all interfaces identified by that address and packets sent to an anycast address are delivered to the any (usually the nearest) interface identified by that address, anycast is a communication between a single sender and any out of multiple receivers.
The Dynamic Home Agent Address Discovery (DHAAD) [D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, IETF RFC 3775, June 2004] uses anycasting to discover an HA address. Anycast routing means that packets are delivered to one out of a group of destinations. The actual receiver can be the one that is closest to the sender or, if all destinations are at the same distance (as in the DHAAD case), the actual receiver can be any one of the destinations, i.e., it is randomly selected.
An MN constructs an anycast address by concatenating the prefix of its home network with a well-known interface identifier. It sends an ICMP (Internet Control Message Protocol) DHAAD Request message to this anycast address. Besides type and code field, this message contains a checksum and an identifier field (see FIG. 1). The latter is required to enable the sender of the request to match the reply to this request. Any one of the HAs on the link receives this anycast message and replies with an ICMP DHAAD Reply message, which contains (besides type, code and checksum field) a list of addresses of HAs on the local link (see FIG. 2). Every HA knows the addresses of all other HAs on the local link from received Router Advertisement messages. Those messages contain the information whether the sender is a router only or can additionally serve as HA. Based on the received list of HA addresses in the DHAAD reply, the MN hence can select one of the addresses and use this as destination address for home registration messages.
Two alternative mechanisms for HA address discovery based on (Domain Name System (DNS) are presented in “Mobile IPv6 bootstrapping in split scenario” [G. Giaretta, K. Kempf, V. Devarapalli, draft-ietf-mip6-bootstrapping-split-00.txt, June 2005]. In one method, the MN requests the address belonging to a well-known HA Fully Qualified Domain Name (FQDN) from the Domain Name System, such as ha1.example.com”. The network operator can perform load balancing by changing the corresponding DNS entry.
In another method, the MN asks the DNS for a HA service and the DNS returns multiple FQDNs, each with weight and preference values set by the operator. Those entries are DNS SRV resource records [A. Gulbrandsen, P. Vixie, L. Esibov, “A DNS RR for specifying the location of services (DNS SRV)”, RFC 2783]. The MN can then select an FQDN based on those values and can request the corresponding IP address from DNS in a subsequent DNS request.
Some infrastructure-based route optimizations protocols like the ones described in “Route Optimization and Location Privacy using Tunneling Agents (ROTA)” [K. Weniger, T. Aramaki, IETF I-D draft-weniger-rota-00.txt, July 2005] and “Providing End-to-End Location Privacy in IP-based Mobile Communication” [WO2004055993] [G. Krishnamurthi, H. Chaskar, R. Siren, IEEE WCNC, March 2004] require the setup of tunnels to/from network infrastructure entities to achieve an end-to-end tunnel between MN and CN, which provides a shorter route. For instance, the usual data path in bi-directional tunnelling mode between two MNs is MN1-MN1's HA-MN2's HA-MN2 (see FIG. 3). Hence, route optimization can be achieved with two concatenated tunnel segments MN1-MN2's HA and MN2's HA-MN2 (see FIG. 4). In case multiple HAs per link exist in this scenario, MN1 has to discover the very HA that is the tunnel endpoint of MN2, i.e., that manages the binding for MN2. Since DHAAD and the DNS-based solution both can only discover any HA address, they cannot be used to solve this problem.
In US2004063402 a method is described for load balancing between HAs using the DHAAD method. Since the HA addresses are selected independently of their binding caches, the proposed method does not solve the given problem either.
In WO2004055993 and “Providing End-to-End Location Privacy in IP-based Mobile Communication” [G. Krishnamurthi, H. Chaskar, R. Siren, IEEE WCNC, March 2004] the problem is solved by sending a unicast request to MN2. Since the only HA in MN2's home network that is on the data path to MN2 is MN2's HA, it can intercept this request message and send a reply. The main drawback of this method is that HAs have to process every data packet in order to check whether the packet contains a request message, even if the packet is not addressed to one of the Home Agent's IP addresses. This can significantly slow down packet forwarding.
The problem to be solved is to discover the IP address of the HA managing a specific binding without requiring HAs to process packets that are not addressed to one of their IP addresses.